---In DynoMotion@yahoogroups.com, <tk@...> wrote:

Hi Jerome,

FYI

The LED on Konnect is just connected to +5V to indicate power is present.

The LEDs on KFLOP are connected to FPGA outputs.  Those require KFLOP to boot up, successfully configure the FPGA, and turn on the outputs for them to go on.

Regards

TK

Group: DynoMotion	Message: 8940	From: fouijar	Date: 1/24/2014
Subject: Re: Mach3 probing setup

Tom, Is the IDC male connector on the board supposed to be like on the Konnect picture of your website? If yes then it's my connector which is reverted on the board... And then I suppose I just need to revert one of the connector on the cable. Maybe not this cable for sure. I uploaded the photo on my folder: Konnect Board Regards, Jerome

Group: DynoMotion	Message: 8941	From: Tom Kerekes	Date: 1/24/2014
Subject: Re: Mach3 probing setup

Hi Jerome, The promotional pictures on our website show the connector reversed. The manuals show it correct here: http://www.dynomotion.com/Help/SchematicsKonnect/ConnectorsKonnect.htm The cable should be a 1:1 cable (pin1 goes to pin1).  The "bumps" should point the same direction. I don't see your photo.  Where did you put it?  Maybe it is a Yahoo delay. Regards TK Group: DynoMotion Message: 8947 From: fouijar Date: 1/24/2014 Subject: Re: Mach3 probing setup Tom, Here is the link of the board view:  http://f1.grp.yahoofs.com/v2/vODiUoyqqbv4Ff-UgC-MEDe37TIPlSsLrUC_Cx-6bbdhUmuPmMn9VHhI5Y3Z4JiY2TjxG9RelibF6YDe6R-0zgW8Q-vDfnyd1YcC7gTMlInwvoJAcV7lkrr4kQWDpNphR_hThnoJhmu-S9SyTziH/Konnect%20board.jpg The way connectors are mounted on the cable is:  CN1 - CN2 1 ------ 16 2 ------ 15 3 ------ 14 4 ------ 13 5 ------ 12 6 ------ 11 7 ------ 10 8 ------ 9 "Bumps" are not in the same direction as they are in a regular polarized map cable, on this cable they are opposed. Following your explanation I need to revert one of the connectors. I'll try that tomorrow when I'll get the connectors and cables. Regards, Jerome Group: DynoMotion Message: 8948 From: Tom Kerekes Date: 1/24/2014 Subject: Re: Mach3 probing setup Hi Jerome, I hope the board isn't blown.  We shipped Konnect with a working 1:1 cable correct? I still can't find the picture.  I think a link like that only works if you are logged in as you. Did you upload a photo or a file?  Which folder? Regards TK Group: DynoMotion Message: 8951 From: fouijar Date: 1/24/2014 Subject: Re: Mach3 probing setup Tom, Well the cable I received is the 1-16 and not 1-1. That's why it didn't boot i guess. The board picture is in Fouijar CNC files, I could find it from my other location, but same login. I can't tell if the board is damaged or not but there was no connection to Konnect board. Well it's late I'll check everything tomorrow I'm not at my workshop. Regards, Jerome Link: http://groups.yahoo.com/neo/groups/DynoMotion/files/Fouijar%20CNC%20Files/ Group: DynoMotion Message: 8954 From: Tom Kerekes Date: 1/24/2014 Subject: Re: Mach3 probing setup Hi Jerome, Your photo shows a Konnect board with the connector installed correctly. My apologies if we included an improperly made cable.  Please post a picture.  We normally test the board with a cable and then leave that same cable installed to ship with, so it would be very difficult to ship an improper cable.  Although if your order was one of the first few boards we didn't have that procedure in place.  If the board is damaged we will replace it. Regards TK Group: DynoMotion Message: 8956 From: fouijar Date: 1/25/2014 Subject: Re: Mach3 probing setup Hello Tom, Well back from the shop where I got cables and connectors, and ready to test the board in a 1-1 cable config. I updated the files in my folder: cable and board pictures are in. I test and come back to you in a few moments. Jerome Group: DynoMotion Message: 8957 From: fouijar Date: 1/25/2014 Subject: Re: Mach3 probing setup Tom, I made a 1-1 cable and started the board, it seems to boot correctly and now I have two questions: 1 - Should I update the firmware like mentioned here:  http://groups.yahoo.com/neo/groups/DynoMotion/conversations/topics/8872 2 - Have you in mind a specific test procedure to check the board? Actual firmware: 4.30h Regrads, Jerome Group: DynoMotion Message: 8959 From: fouijar Date: 1/25/2014 Subject: Re: Mach3 probing setup Tom, Boot is ok. Last update: firmware change to 4.31r Input test: the LEDs, light no state change seen in Digital I/0 screen. Output test: SetBit 48-63 within the console=> no state change at the outputs. Regards, Jerome Group: DynoMotion Message: 8960 From: Tom Kerekes Date: 1/25/2014 Subject: Re: Mach3 probing setup Hi Jerome, ok sorry from your photo we sent an improper cable. Are you enabling Konnect with C code: (for connection to JP6)     InitAux();     AddKonnect(0,&VirtualBits,VirtualBitsEx); (for connection to JP4)     InitAux();     AddKonnect_Aux0(0,&VirtualBits,VirtualBitsEx); Regards TK Group: DynoMotion Message: 8964 From: fouijar Date: 1/25/2014 Subject: Re: Mach3 probing setup Tom, Well I did the test using the code InitAux(); AddKonnect(0,&VirtualBits,VirtualBitsEx); Then using while and for loops I tested and printed the results of I/0 states. Commands are well executed but no input detected and outputs remain shut. On top of that I did a complete shut down and restart, followed by a nice crash due to KFlop unwanted SW0-7 and opto outs actions. Even if SWE is present... i mean should disable until ready. So, I think the Konnect board is out unless I miss something (I've checked the I/O diagram between boards...). And the KFlop crash sounds bad to me, but not as much as the ATC crashing on the spindle due to the "false command", :( . Best regards, J. Group: DynoMotion Message: 8966 From: Tom Kerekes Date: 1/25/2014 Subject: Re: Mach3 probing setup Hi Jerome, After the Konnect is added by executing the code, KFLOP will continuously be reading a signature from Konnect and verifying proper communication.  This would test the communication to and from Konnect.  If an error is ever detected a message should display on the Console and further communication will be disabled. Do you see an error message on the Console Screen? Which connector are you connecting to? I don't understand the crash.  Are you referring to Kanalog?  Are you using SWE properly? Regards TK Group: DynoMotion Message: 8971 From: fouijar Date: 1/25/2014 Subject: Re: Mach3 probing setup Tom, Below the test code used: #include "KMotionDef.h" InitAux(); AddKonnect(0,&VirtualBits,VirtualBitsEx); main() {     int n;     int i;     for (n=48;n<=63;n++)         {             SetBit(n);             ReadBit (n);             printf("Bit n=%d State=%d\n", n,ReadBit(n));             Delay_sec(0.25);             ClearBit(n);             printf("Bit n=%d State=%d\n", n,ReadBit(n));         }     for(i=1024;i<(1024+8);i++)// Test starts at 1024 to test the first input bank     {            printf("Bit# %d State=%d\n", i,ReadBit(i));            Delay_sec(0.25);     } } Console results: Bit n=48 State=1 Bit n=48 State=0 Bit n=49 State=1 Bit n=49 State=0 Bit n=50 State=1 Bit n=50 State=0 Bit n=51 State=1 Bit n=51 State=0 Bit n=52 State=1 Bit n=52 State=0 Bit n=53 State=1 Bit n=53 State=0 Bit n=54 State=1 Bit n=54 State=0 Bit n=55 State=1 Bit n=55 State=0 Bit n=56 State=1 Bit n=56 State=0 Bit n=57 State=1 Bit n=57 State=0 Bit n=58 State=1 Bit n=58 State=0 Bit n=59 State=1 Bit n=59 State=0 Bit n=60 State=1 Bit n=60 State=0 Bit n=61 State=1 Bit n=61 State=0 Bit n=62 State=1 Bit n=62 State=0 Bit n=63 State=1 Bit n=63 State=0 Bit# 1024 State=0 Bit# 1025 State=0 Bit# 1026 State=0 Bit# 1027 State=0 Bit# 1028 State=0 Bit# 1029 State=0 Bit# 1030 State=0 Bit# 1031 State=0 This is OK, but there's no indication on the INPUT state of Bit#1024 wihch is 1 and remains one (LED on). The output has been tested using a multimeter to check if the gate conducts and no => kept blocked. I have no warning message. Regards, J. Group: DynoMotion Message: 8972 From: Tom Kerekes Date: 1/25/2014 Subject: Re: Mach3 probing setup Hi Jerome, The two lines of code are not inside the main() function.  Execution begins at the beginning of the main function so they never get executed. (I'll have to look at why that doesn't generate an error.  I suppose the just re-declares the routines); Are you connected to JP4 or JP6? You don't really need your program as you can see and change IO on the digital IO screen. Regards TK Group: DynoMotion Message: 8974 From: fouijar Date: 1/25/2014 Subject: Re: Mach3 probing setup Tom, Well I'm using the JP6 so the lines of code are well the ones dedicated to JP6. It works now but the I/0 screen doesn't shows anything before a C code execution. Once executed the I/0 screen permits to activate outputs independently and also check the Inputs. From what I could check the board seems to be ok but that doesn't explain the crash. About SWE, it drives a relay to activate a secondary PSU used for logic and control. The problem was like when the Kanalog ICs where burned and blocked in a transient state, not really closed not really open. from now after 3-4 boots all seems to be functional and the start-up sequence of SWE is respected. I can't explain why since every relay is driven through a "Darlington circuit" and fly-back diodes are installed. This was discussed in depth about +18 months ago, all the circuitry was adapted to the best practices and valuable recommendations. Again, thanks for you help and support. I'll update the system and well be more involved with Konnect from now. Best regards, Jerome Group: DynoMotion Message: 8992 From: fouijar Date: 1/26/2014 Subject: Re: Mach3 probing setup Tom, When I'm using the 4.31r firmware I have a problem with mach3. Taken from the log file: Pos Limit Disabled Axis:1 // Y axis stopping abruptly Pos Limit Disabled Axis:1 // the same Mach3 Home Call, flags = 2 // I homed the axis to re ref the system Pos Limit Disabled Axis:1 //As above Pos Limit Disabled Axis:2 // Z also bugging. I came back to 4.30h to test and everything works smooth without any troubles. Do you have an idea of what's going wrong? What does mean : Pos Limit Disabeld Axis ? May I copy the headers differences between KmotionDef v4.31r to v4.30h? I suppose doing so will simply give me the same results as going to v4.31r. Thanks for your attention, Jerome Group: DynoMotion Message: 8994 From: Tom Kerekes Date: 1/26/2014 Subject: Re: Mach3 probing setup Hi Jerome, Pos Limit Disabled Axis:1 Means that in your configuration you have Positive End Limit Switch Options set for axis #1 to disable the Axis if the configured Limit Input goes active, and KFLOPdetected the Limit bit active and disabled the axis. How do you have your Limit Option Configured?  When do you get the error?  What have you changed besides Versions? No you can not copy headers from one Version to another.  The Header definitions must exactly match the version of firmware that is executing or a crash would be likely. Regards TK Group: DynoMotion Message: 9000 From: fouijar Date: 1/26/2014 Subject: Re: Mach3 probing setup Hi Tom, This is my actual configuration: X: negative limit, Stop when low, bit# 143 Y: positive limit, Stop when low, bit# 136 Z: positive limit, Stop when low, bit# 142 Nothing has changed system and configuration remain the same. In the headers I found these changes from 4.30h to 4.31r at lines 298, 299:     int LimitSwitchNegBit;            // Neg Limit I/O Bit number     int LimitSwitchPosBit;            // Pos Limit I/O Bit number Since the configuration was done under older version does these changes affect the way the code is handled, I mean in this particular case? I suppose it does since these variables are defined in the header. I'm not at my workshop and Reboot! doesn't work, or change the version displayed. So at the moment it's not possible to investigate the flash and config under v 4.31r. Regards, Jerome ---In DynoMotion@yahoogroups.com, <tk@...> wrote: Hi Jerome, Pos Limit Disabled Axis:1 Means that in your configuration you have Positive End Limit Switch Options set for axis #1 to disable the Axis if the configured Limit Input goes active, and KFLOPdetected the Limit bit active and disabled the axis. How do you have your Limit Option Configured?  When do you get the error?  What have you changed besides Versions? No you can not copy headers from one Version to another.  The Header definitions must exactly match the version of firmware that is executing or a crash would be likely. Regards TK Group: DynoMotion Message: 9002 From: Tom Kerekes Date: 1/26/2014 Subject: Re: Mach3 probing setup Hi Jerome, I found a bug.   Sorry about that.  It is difficult to explain: Version 4.30h is limited to 8-bit IO bit numbers for limit switches.  All the limit options (enables, polarities, mode, positive bit number, and negative bit number) were packed into a 32-bit word. To allow bit numbers greater than 255 we added 2 more 32-bit words for the positive and negative bit numbers (the fields you noticed). We tried to make it backward compatible.  If bit 8 in the original word is zero it uses the old packed method.  If set, it uses the two new words. We have a bug when trying to use the old method where the Negative bit number is being used for both the Positive and Negative directions. Please use the new method.  If you use KMotion to Import settings from your legacy C program and Export back to the C file it should convert things to the new method automatically. Let us know if this isn't clear  Regards TK Group: DynoMotion Message: 9004 From: fouijar Date: 1/26/2014 Subject: Re: Mach3 probing setup Tom, Thanks for your explanation. I'll have a try tomorrow and give you the results. Regards, J. Group: DynoMotion Message: 9016 From: fouijar Date: 1/27/2014 Subject: Re: Mach3 probing setup Hello Tom, I updated the Init file to match the new firmware version and from what I could test it's working fine. Probing routine is also functional. Everything boot nicely, no errors at this point. Thanks for your support, Jerome Group: DynoMotion Message: 9017 From: Tom Kerekes Date: 1/27/2014 Subject: Re: Mach3 probing setup Hi Jerome, Thanks you for reporting back. Regards TK Group: DynoMotion Message: 9055 From: fouijar Date: 1/30/2014 Subject: Re: Mach3 probing setup Hello, Just a quick question, why when I try to get the actual position of the triggering point I receive a 0 instead of tha actual position counts? ... double Xp; main{ ... Xp=ch0->Position; printf("Xp=%d\n",Xp); ... } Thanks for your attention, Jerome Group: DynoMotion Message: 9056 From: Tom Kerekes Date: 1/30/2014 Subject: Re: Mach3 probing setup Hi Jerome, Not sure exactly what you mean.  But in a printf format string to print a floating point value (double) you must use %f not %d. Regards TK Group: DynoMotion Message: 9057 From: fouijar Date: 1/30/2014 Subject: Re: Mach3 probing setup Hi Tom, Thanks for your answer. I missed that point. What would be the best option to get the triggering point and passing the data to Mach3? - Write a C# program and use a macro to call for specific actions like passing the axis trig. point for, ie, define a new work offset? - What would be the best way to get the data and pass it to Mach3 ?     Xp=(ch0->Position)/(counts/unit);// convert the position from counts to abs. coord units - And is it existing a specific C# function to get the position in absolute coord. value like GetABSPosition? Best regards, Jerome ---In DynoMotion@yahoogroups.com, <tk@...> wrote: Hi Jerome, Not sure exactly what you mean.  But in a printf format string to print a floating point value (double) you must use %f not %d. Regards TK Group: DynoMotion Message: 9058 From: Tom Kerekes Date: 1/30/2014 Subject: Re: Mach3 probing setup Hi Jerome, I don't understand your issue. The Probe Trip point is automatically passed up to the Mach3 #2000 Vars.  See: http://dynomotion.com/Help/Mach3Plugin/Mach3Probe.htm Regards TK Group: DynoMotion Message: 9059 From: fouijar Date: 1/31/2014 Subject: Re: Mach3 probing setup Hello Tom, I found that the value passed to Mach3 is somewhat different than the value I get in the C# program. Xp=(ch0->Position); gives: Xp Position is -58294.000000 When I go in the Console after G31 and G1 X#2000, position is: -58299.0 The delta is usually comprised within the range = 4<delta<10 counts. This is probably because of the C# program structure and the time for execution before storing the data. That's why I was investigating the way to get the most accurate triggering point value. Having the triggering point captured as I do in the while loop or just after doesn't changes anything but is well different from the valued passed to Mach3. I hope I'm a bit more clear to understand this way. Thanks for your attention. Best regards, Jerome For reference the portion of code I use to get the mentioned results:     if (msg==20000)     {         double *d = (double *)&persist.UserData[MACH3_PROBE_RESULTS_VAR];         if(ReadBit(PROBE_BIT)==0)flag=1;         printf("d is %f\n",*d);         persist.UserData[MACH3_PROBE_STATUS_VAR]=PROBE_ERROR_HANDLING;         printf("1st Probe Status, Bit 22 = %d\n",ReadBit(PROBE_BIT));         printf("Flag is %d\n",flag);         while (ReadBit(PROBE_BIT)!=PROBE_ACTIVE_STATE)         {             //flag=2;              Xpw=ch0->Position;             WaitNextTimeSlice();         }         Xp=ch0->Position;         printf("Xpw Position is %f\n",Xpw);         printf("Xp Position is %f\n",Xp);         flag=2;         printf("Flag is %d\n",flag);         printf("Probe active state is: %d\n",PROBE_ACTIVE_STATE);         printf("2nd Probe Status, Bit 22 = %d\n",ReadBit(PROBE_BIT));         if (CS0_axis_x>=0) d[0]=chan[CS0_axis_x].Dest;         if (CS0_axis_y>=0) d[1]=chan[CS0_axis_y].Dest;         if (CS0_axis_z>=0) d[2]=chan[CS0_axis_z].Dest;         if (CS0_axis_a>=0) d[3]=chan[CS0_axis_a].Dest;         if (CS0_axis_b>=0) d[4]=chan[CS0_axis_b].Dest;         if (CS0_axis_c>=0) d[5]=chan[CS0_axis_c].Dest;                 persist.UserData[MACH3_PROBE_STATUS_VAR]=flag;         StopCoordinatedMotion();         printf("Flag is %d\n",flag);         printf("3th Probe Status, Bit 22 = %d\n",ReadBit(PROBE_BIT)); Group: DynoMotion Message: 9060 From: fouijar Date: 1/31/2014 Subject: Re: Mach3 probing setup Tom, I spoke too fast about Xp and Xpw. I tested the feed rate to check if the triggering point captured would change and yes the delta is even more increasing with higher feed rate but not only as previously explained. Now I can see a delta between the tests in while loop and after. => Xpw and Xp : 2 counts @200mm/min =>Xp to X#2000 >15 counts. Feed rate of G1 has no influence on the X#2000 positioning results. Regards, Jerome Group: DynoMotion Message: 9061 From: Tom Kerekes Date: 1/31/2014 Subject: Re: Mach3 probing setup Hi Jerome, You confused me at first with the C# reference.  KFLOP runs C which is arguably the most simple/fast/lightweight/popular/cross platform language in the world.  Which is why KFLOP uses it :}   C# is a newer/more advanced/complex/Microsoft .NET language used mainly fro writing MS Windows GUIs.  See: http://langpop.com/ But anyway, I think there are 4 issues related to what you are seeing: #1 probe sample rate #2 Destination vs Position #3 sampling before or after the event #4 printf's take time to execute   #1 - The software loop sampling the Probe Input is guaranteed to run every 180us.  See: http://dynomotion.com/Help/Multitasking.htm This makes an uncertainty in time of +/- 90us of when the probe is actually detected.  At a speed of 100mm/min that corresponds to +/- 0.15um.  At 1000mm/min it corresponds to +/- 1.5um.  Slower is better. #2 - With a servo system there is the position where the axis is supposed to be on the trajectory (we refer to this as the Dest), and where the axis actually is based on the encoder (we refer to this as the Position).  A well tuned servo system should drive the Position to be nearly equal to the Dest within several encoder counts.  Especially when moving slowly and at constant velocity.  You can easily observe how well your axis works using the Step Response Screen.   When probing it is probably better to capture the Position rather than the Dest which should eliminate any servo error.  Our example captures the Dest because not everyone has encoder feedback.  To change to capture Position instead change:         if (CS0_axis_x>=0) d[0]=chan[CS0_axis_x].Dest;         if (CS0_axis_y>=0) d[1]=chan[CS0_axis_y].Dest;         if (CS0_axis_z>=0) d[2]=chan[CS0_axis_z].Dest;         if (CS0_axis_a>=0) d[3]=chan[CS0_axis_a].Dest;         if (CS0_axis_b>=0) d[4]=chan[CS0_axis_b].Dest;         if (CS0_axis_c>=0) d[5]=chan[CS0_axis_c].Dest; to:         if (CS0_axis_x>=0) d[0]=chan[CS0_axis_x].Position;         if (CS0_axis_y>=0) d[1]=chan[CS0_axis_y].Position;         if (CS0_axis_z>=0) d[2]=chan[CS0_axis_z].Position;         if (CS0_axis_a>=0) d[3]=chan[CS0_axis_a].Position;         if (CS0_axis_b>=0) d[4]=chan[CS0_axis_b].Position;         if (CS0_axis_c>=0) d[5]=chan[CS0_axis_c].Position; #3 Your code:         while (ReadBit(PROBE_BIT)!=PROBE_ACTIVE_STATE)         {             //flag=2;              Xpw=ch0->Position;             WaitNextTimeSlice();         } samples the Position one time slice (180us) before the Probe Changes State.  Our code samples on the same time slice as it changes.  That adds a 180us difference. #4 diagnostic printf statements are actually very computationally intensive.  The format must be parsed, lots of floating point math to convert number formats, logging to the console, etc...  I timed the 5 diagnostic printfs that you added to take 780us to execute.  You added them before the Dest was captured.  If you would have added the printfs after the Dest had already been captured, it wouldn't have added any delay in the measurement. In summary: Change from Dest to Position, capture your value after the switch changes, and move any printfs after the capture and your results should be very good. Regards TK Group: DynoMotion Message: 9062 From: fouijar Date: 1/31/2014 Subject: Re: Mach3 probing setup Hi Tom, Yeah sorry for C#, I'm a occasional program writer... ;) And thank you for your very clear explanation. I was aware about the sampling rate and delays but your detailed review makes it cristal clear. I'm not often enough working with C and the commands/functions dedicated to Kmotion uses. From now I'll suppress the printfs, they where used to help understand the triggering process and actions ongoing. I had some issues when first using the Konnect board. That's why I used them for state changes monitoring. In the future I would like to use linear encoders I have for position feedback correction and servo encoders for speed/accel loops. Is it possible to do it from the actual servo loop diagram? I'm not sure because there's only one encoder channel per axis. Is it a possibility to change that? Thanks again for your help. Best regards, Jerome Group: DynoMotion Message: 9063 From: Tom Kerekes Date: 1/31/2014 Subject: Re: Mach3 probing setup Hi Jerome: Regarding Dual Loop:  You can do this but it requires two KFLOP Axis Channels connected together.  It works nice because you can tune each loop independently and you have a full set of parameters PID, Filters, etc... for each loop.  The disadvantage is that it consumes two axis channels for each loop. It is more common to have the amplifier handle the inner loop. Regards TK Group: DynoMotion Message: 9064 From: fouijar Date: 1/31/2014 Subject: Re: Mach3 probing setup Hi Tom, Thanks for your feedback. I changed the code to follow your explanation and now Position=Dest. The Value captured is the same as the final destination/position after G31, G1. No count error, nearly. I'm actually using the Konnect board to capture the triggering point but should re-arrange my inputs to suit speed dependent actions. I think getting an ATC cylinder position is not a priority compared to probing... Many many thanks for your help, really. Regards, Jerome